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(54) Title: METHOD AND SYSTEM FOR ELECTRONICALLY MANAGING AND REIMBURSING MEDICAL CARE 
(57) Abstract 



A system for guiding medical service providers in making referrals 
and in providing services that are automatically authorized for specified 
payments. Upon an initial encounter With a patient, the system guides a 
user through identifying insurance plan member information, verifying 
patient number and eligibility, and identifying related past encounter. 
The system then assists the user in creating a referral that authorizes 
a performing provider to provide certain medical services which are 
guaranteed to be reimbursed at a determinable level. The system guides the 
user in specifying a referring and performing provider, a type of facility, 
a referral basis and treatment type suggestions, and an urgency level. For 
each specification, the system indicates choices for which the system can 
automatically authorize a referral that results. The system also assists 
review users in manually authorizing referrals that the system cannot 
automatically authorize. When a person seeks care from a preforming 
provider for which an authorized referral exists, the system retrieves 
relevant patient medical history and assists a user in specifying authorized 
diagnosis and service codes, corresponding to the medical diagnoses made 
and the medical services provided, such that the provider is guaranteed to 
receive a determinable payment. If diagnosis or service codes are specified 
for which the system cannot automatically authorize payment, the system 
assists review users in manually adjucating and authorizing the payment 
to be received. When services are authorized for payment, the system 
automatically makes payment. 
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METHOD AND SYSTEM FOR ELECTRONICALLY MANAGING 
AND REIMBURSING MEDICAL CARE 

TECHNICAL FIELD 

The present invention relates generally to improving medical care, and 
5 more particularly to guiding medical service providers through providing services and 
making referrals that are automatically authorized for payment. 

BACKGROUND OF THE INVENTION 

In the current environment where costs associated with medical care are 
closely managed, medical service providers ("providers") such as doctors, hospitals, and 

0 labs are often limited in the types of medical services (i.e.. procedures and products) 
which they are authorized to provide. For example, insurance plans will typically 
provide payment for services only if the necessity for the services is justified and the 
services arc covered by the insurance plan. Similarly, incentives to restrict unwarranted 
services exist for managed care organizations, such as physician groups with capitated 

5 contracts in which a fixed monetary amount is received for each covered patient. 

Even if a provider knows that a particular service is authorized for a 
'particular patient, it is often necessary for the provider to submit a claim in the 
appropriate format and with the correct information to ensure that the provider will 
receive payment. For example, many insurance plans require the use of diagnosis and 

0 service codes in their claims to describe respectively a patient's problems and the 
services provided to address the problems. A common example of diagnosis codes is 
the International Classification of Diseases. 9th Revision (ICD-9) code set based on 
U.S. Department of Health and Human Services Publication No. (PHS) 91-1260. 
Similarly, many insurance plans use a code set of Common Procedure Techniques 

5 (CPT) codes to reflect services supplied by doctors. Other types of providers use other 
common sets of codes (e.g., HCPC codes for hospitals). 

The complexity of medical care has led to large numbers of codes in 
most code sets, including thousands of diagnosis and service codes. These large 
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numbers make the selection of appropriate codes difficult. Merely finding appropriate 
codes from among the many possibilities can be a significant challenge. Moreover, it is 
often the case that two or more codes can be used to describe a diagnosis or a service, 
but an insurance plan may provide payment for only some of the possible codes. Thus. 
5 even if a patient's insurance plan would be willing to fully reimburse an appropriate 
claim for a particular type of service performed, it is difficult for a provider to select the 
appropriate diagnosis and service codes to ensure that payment will be received. 

Moreover, even if diagnosis and service codes are correctly supplied, 
receiving payment for services can be time-consuming and subject to error. For 

10 example, claims have historically been submitted on paper forms. Each time the 
information on the form must be re-entered into a computer system, such as when the 
insurance plan determines payment, it is possible for errors to be introduced. In 
addition, the insurance plan and/or a managed care organization's Utilization 
Management (UM) group must process each claim, check patient eligibility, verify that 

15 a performing provider (i.e.. the provider performing a service) is authorized to provide 
the particular service or that a referring provider (i.e., the provider making a referral) is 
authorized to make the referral, check the maximum benefit for the service provided, 
and submit payment to the appropriate providers. After submitting a claim, a provider 
* must track the status of the claim while waiting for reimbursement, match payments 

20 received to the appropriate services provided, post payments to the appropriate claim, 
and deal with denials and adjustments. In addition, a UM group may need to audit 
claims that are paid and identify errors, and the insurance plan must adjust later 
payments to the provider to reflect errors made. It is not uncommon for this procedure 
to take several months. 

25 The current situation is made even more difficult for providers because 

they typically do not know whether particular services are covered for a particular 
patient, and if so, at what level they will be compensated. Thus, when a patient first 
comes to a provider, the provider must attempt to verify the status of a patient as an 
eligible member of an insurance plan and to determine the types of services that will be 

30 covered for this patient. Covered services will vary for each insurance plan, and can 
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even vary for individual patients within a plan. Due to these various uncertainties, 
providers can wait for many months before knowing whether and how much they will 
be paid for services performed. 

A similar situation exists for referrals made for extended care or for 
5 specialized services. Not only is it difficult for the referring provider to know whether 
the referral will be covered by the insurance plan, it is also difficult for a referring 
provider to know exactly what specialty service is needed. For example, a general 
practitioner may know that a patient has some type of heart irregularity, but may not be 
qualified or authorized to make the particular diagnosis needed to recommend ICD-9 

10 and CPT codes. A specialist performing provider who receives a referral may be even 
less familiar with the services typically covered by a particular insurance plan, and thus 
may face even greater uncertainty about the possibility of payment. 

Thus, for both services performed and referrals made, the current 
situation requires significant effort by providers to receive payment and creates 

15 uncertainty and delay in their receipt. While uncertainty can be reduced for services 
that can be postponed until they can be pre-authorized by the insurance plan, that is also 
a time-consuming process and may still not indicate the precise amount of payment that 
will be received. The current situation also requires significant effort by insurance 
* plans and UM groups to track referrals and services performed, to preauthorize a variety 

20 of referrals and services, to determine whether to authorize payment for claims, and to 
supply and track payments. The current situation is also frustrating for patients because 
each time they visit a new provider they must re-specify a variety of patient data before 
receiving care, and the provider will have to re-enter information about past services 
provided and any current referral. 

25 SUMMARY OF THE INVENTION 

Some embodiments of the present invention provide a method and 
system for guiding medical service providers in making referrals and in selecting 
services to be provided that are automatically authorized for specified payments. The 
system creates and shares electronic patient claim records (PCRs) that are transferred 
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between providers and other authorized users, and that are automatically paid when they 
are either automatically or manually authorized. When a patient first visits a provider, 
the system assists the provider to determine patient eligibility and to identify relevant 
patient medical history and related past treatments. If the patient is to be referred to a 
5 performing provider for the provision of medical services, the system assists the user in 
specifying the referring and performing providers, a referral basis, a type of facility for 
treatment, a suggested type of treatment, and an urgency of treatment. As each 
specification is made, the information is stored in the PCR. For each specification, the 
system provides possible choices for which the system can automatically authorize 

10 payment, with the capability to restrict these possible choices based on previous 
specifications and other relevant information. 

If a referral is automatically authorized, the corresponding PCR is 
immediately forwarded electronically to the selected performing provider without 
requiring manual review. When a performing provider is to treat a patient, the system 

15 assists a user in specifying diagnosis and service codes for which the system can 
automatically authorize payment. If the treatment is automatically authorized, a 
payment amount is automatically determined and disclosed to the performing provider, 
and the determined amount is automatically paid. If a referral, treatment, or payment 
"request cannot be automatically authorized, the system forwards the corresponding PCR 

20 to an appropriate person for rapid manual approval of the request. The appropriate 
person may be any person at a specified review level (e.g.. any Utilization Review 
nurse) or a specific person (e.g., a particular case manager). The system also supports 
specialized functionality, such as separate support functions for hospital performing 
providers. For such performing providers, the system tracks information such as 

25 admission and discharge dates as well as journal entries made. 

In one embodiment, all users of the system are in constant two-way 
computer communication, such as via a network of computers or via terminals attached 
to a shared server. In this embodiment, PCRs and other messages can be forwarded to 
users in a variety of ways, such as via messages sent to and stored on local computers or 

30 as information stored on a central server for retrieval by the appropriate clients. In 
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another embodiment, some users are contactable in other ways such as by one-way or 
two-way pager, cellular phone, voice mail. etc. For example, a physician who. can 
manually approve a type of procedure may carry a pager rather than be tied to a 
particular computer. The system tracks the status of various users, and forwards 
5 information to them in the manner appropriate for that user. Thus, if a destination user 
has access to a computer connection, a PCR can be forwarded to the user as an object or 
as email. Alternately, if the user has a communication device such as a pager or a 
phone, the system can convert the information from the PCR into an appropriate 
alphanumeric or spoken format so that the user can receive the information on their 
1 0 communication device. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram illustrating an embodiment of the Electronic 
Managed Care Commerce (EMCC) system of the present invention. 

Figures 2-15 are example user interface screens of an EMCC system. 
15 Figure 16 is a block diagram illustrating an embodiment of an EMCC 

system. 

Figures 1 7A and 1 7B are exemplary flow diagrams of an embodiment of 
* the Gatekeeper routine. 

Figure 18 is an exemplary flow diagram of an embodiment of the 
20 Designate Referral Information subroutine. 

Figure 1 9 is an exemplary flow diagram of an embodiment of the Select 
An Instance Of Specified Type Of Information Based On Specified Context Of Past 
Selections subroutine. 

Figures 20A and 20Bare exemplary flow diagrams of an embodiment of 
25 the Remote Distribution subroutine. 

Figure 21 is an exemplary- flow diagram of an embodiment of the 
Authorization routine. 

Figure 22 is -an exemplary flow diagram of an embodiment of the 
Performing Provider routine. 
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Figure 23 is an exemplary flow diagram of an embodiment of the 
Hospital routine. 

Figure 24 is an exemplary flow diagram of an embodiment of the 
Adjudication routine. 

5 Figure 25 is an exemplary flow diagram of an embodiment of the Paylist 

Routine. 

DETAILED DESCRIPTION OF. THE INVENTION 

An embodiment of the present invention provides a method and system 
for guiding medical service providers ("providers*;) in making referrals and in selecting 

10 services to be provided that are automatically authorized for specified payments. In 
particular, the Electronic Managed Care Commerce (EMCC) system creates and shares 
electronic patient claim records (PCRs) that are transferred between providers and other 
users, and that are automatically paid when they are either automatically or manually 
authorized. Since referrals and services can be automatically authorized for guaranteed 

15 payment, uncertainty of providers about reimbursement and under-payments can be 
reduced and the need of insurance plans and/or UM groups to review many claims can 
be eliminated. In one embodiment, the EMCC system consists of an EMCC Server 
* computer which stores a variety of information centrally and coordinates activity 
between a variety of different EMCC client computers or terminals at various locations. 

20 When a person first seeks care from a provider (e.g., their primary care 

provider), a user at that location uses an EMCC Gatekeeper module to initiate the 
provision of medical care to the person. The Gatekeeper module acts as an entry point 
into the EMCC system by guiding the user through specifying various information that 
will ultimately create a referral to a provider for specified types of treatment. For each 

25 specification to be made by the user, the Gatekeeper module uses past user 
specifications and other available information to provide a context for displaying only 
relevant information, including indicating available choices for which the resulting 
referral can be automatically authorized for payment by the EMCC system. 
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The Gatekeeper module begins a referral by creating an electronic 
patient claim record (PCR) for the patient. The PCR represents the current encounter as 
well as any subsequent referral and services, storing information related to the 
encounter such as information specifications made by the user. The Gatekeeper module 
5 assists the user in determining patient eligibility and in displaying patient medical 
history, including indicating any referral history and past encounters related to the 
present visit. For example, to assist in determining patient eligibility, the Gatekeeper 
module can retrieve from the EMCC Server a list of insurance plan members who are 
eligible for medical treatment. This list could include any member of which the EMCC 

10 system was aware, or only those members relevant to the current provider (e.g.. for a 
solo practitioner, only those patients for whom she is their primary care provider). 
After the member information for the patient is selected by the user, the Gatekeeper 
module can similarly assist in displaying patient medical history by retrieving other 
PCRs for this patient. The retrieved PCRs could include all PCRs for the patient, or 

15 only those PCRs which have previously been designated as being related to the current 
PCR through the creation of an association between them (e.g.,- if the current PCR 
represents the continuing treatment of a previously treated problem). 

The Gatekeeper module next assists the user in specifying the referring 
• and performing providers for the referral. While the referring provider will often be the 

20 primary care provider for the patient, other. providers (e.g., a nurse practitioner or a 
hospital) may also be authorized to make a referral depending on the insurance plan, the 
patient, and the past treatment. A variety of providers can similarly be specified as the 
performing provider. For example, a patient. may be referred to a specialist provider, or 
a primary care provider may specify a self-referral in which the primary care provider is 

25 both the referring and performing provider. As mentioned, when the user is to specify 
information such as the referring or performing providers, the Gatekeeper module will 
indicate the possible choices that can be automatically authorized by the EMCC system. 
In one embodiment, the context of past user specifications will be used to determine the 
list of authorizable choices for the current specification. For example, when a patient 

30 first sees their primary care provider for an infection, the only authorized referral and 
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services may be for that provider to prescribe antibiotics. However, if this treatment is 
not effective, the context of this past treatment selection may allow a later referral to a 
specialist to be automatically authorizable. Similarly, when the head of a medical 
department is acting as a referring provider, he may have a wider range of performing 
5 providers to which referrals can be automatically authorized than would the average 
primary care provider. 

After specifying referring and performing providers, the Gatekeeper 
module assists the user in specifying a referral basis that indicates the type of patient 
problem (e.g.. a suspected heart valve disorder), a type of facility for treatment {e.g., a 

10 physician's office), a suggested type of treatment by the performing provider (e.g., 
evaluate and treat, or only perform lab tests), and an urgency of treatment (e.g., 
emergency). The Gatekeeper module also can assign an appropriate referral review 
level (e.g., a Utilization Review nurse) if manual review is needed, and can identify 
patient-specific risk factors related to the specified referral basis and suggested type of 

15 treatment (e.g., patient's smoking may be related to heart problems). After all of the 
specifications have been made, the Gatekeeper module will notify the EMCC Server to 
make the electronic PCR available to the appropriate provider or other user. Those 
skilled in the art will appreciate that while the Gatekeeper module is often used by a 
" primary care provider during an initial consultation with a patient, it can also be used by 

20 other providers at other times (e.g., a specialist performing provider who receives a 
referral which authorizes one type of service may perform a self-referral to authorize 
additional types of service). 

If the user of the Gatekeeper module selects only choices indicated to be 
automatically authorizable. then the EMCC system automatically authorizes the referral 

25 and the PCR is immediately sent to the selected performing provider. However, if the 
user instead made one or more selections which could not be automatically authorized, 
the PCR is sent to one or more users at the specified review level for the PCR (e.g., to 
one or more Utilization Review 7 nurses) for manual authorization. A user such as a 
Utilization Review (UR) nurse will use an EMCC Authorization module to receive and 

30 review such PCRs. The Authorization module can display the information in the PCR 
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and retrieve additional related information from the EMCC Server (e.g.. patient medical 
history or performance data for the referring provider). The Authorization module user 
can then manually authorize the referral, either as-is or as modified by the user. 
Alternately, the PCR can be transferred to a user at a higher review level for 
5 authorization. Upon manual authorization, the PCR is forwarded to the selected 
performing provider by the EMCC Server. This manual authorization process can be 
completed in a matter of minutes, with the authorization received while the patient is 
still at the provider's location. 

When the patient seeks medical care at the performing provider, a user at 
10 that location uses an EMCC Performing Provider (PP) module to display the electronic 
PCR for the person. The availability of the PCR indicates that the referral to the 
performing provider has been authorized, either automatically by a Gatekeeper module 
or manually by an Authorization module. If the Gatekeeper module is used to make a 
self-referral where the current provider is both the referring and performing provider, 
15 then the user at that location can merely switch from the Gatekeeper module to the PP 
module and continue the encounter. 

The PP module assists a user in viewing information from the PCR for 
the patient, and can retrieve and display related information from the EMCC Server 
'such as patient medical history or patient demographic information. The PP module 
20 then assists the user in specifying one or more diagnosis codes related to medical 
problems of the patient, and one or more service codes related to services provided to 
the patient by the performing provider. As each specification is made, the information 
is stored in the PCR. As with the Gatekeeper module, the PP module indicates choices 
for the diagnosis and service codes that can be automatically authorized by the EMCC 
25 system. In one embodiment, the context of past specifications, including specifications 
from any referrals leading to treatment, will be used to determine the list of authorizable 
choices for the current selection. If the user of the PP module selects only choices 
which the EMCC system can automatically authorize, then the services are 
automatically authorized. If so ? the PP module determines the payment that will be 
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received for the authorized services, and the PCR is sent to a Paylist module for 
immediate payment. 

The EMCC system can also support specialized modules. For example, 
while hospitals are one type of performing provider, the EMCC system can have an 
5 EMCC Hospital module which is unique from the PP module. When the patient seeks 
medical care at the hospital, a user at that location uses a Hospital module to display the 
electronic PCR for the person. In addition to the functions performed by the PP 
module, the Hospital module can assist the user in performing hospital-specific 
activities such as admitting and discharging the patient and recording journal entries for 

10 the period during which the patient is admitted. If the hospital provides only services 
which the Hospital module can automatically authorize, then these services are 
automatically authorized, the payment that will be received is automatically determined, 
and the PCR is sent to the Paylist module for immediate payment. 

If the user of a PP or Hospital module specifies choices which cannot be 

15 automatically authorized, then the PCR is sent to one or more users for manual 
adjudication of whether payment will be supplied. As with Authorization modules, 
various review levels can be specified for manual adjudication. An adjudication user 
will use an EMCC Adjudication module to receive and review such PCRs. The 
Adjudication module can display the information in the PCR and retrieve additional 

20 related information from the EMCC Server. A user can then use the Adjudication 
module to manually authorize a specified amount of payment for specific services. 
Upon manual authorization of payment, the PCR is forwarded to the Paylist module for 
immediate payment. As with the Authorization module, manual authorization from the 
Adjudication module can be received in a matter of minutes. When the Paylist module 

25 receives a PCR authorized for a specified payment, the Paylist module can make 
immediate payment to the appropriate provider electronically wiring funds or 

debiting a provider account maintained by the EMCC system). 

In one embodiment, all users of the EMCC system are in constant two- 
way computer communication, such as via a network or via terminals attached to a 

30 shared server. In this embodiment. PCRs and other messages can be forwarded to users 
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in a variety of ways, such as via messages sent to and stored on local computers or as 
information stored on the EMCC Server for retrieval by the appropriate EMCC module. 
In another embodiment, some users are contactable in a variety of other ways such as by 
one-way or two-way pager, cellular phone, voice mail. etc. The system tracks the status 
5 of various users, and a Remote Distribution (RD) module can be used by the EMCC 
system to receive a PCR or other information and to forward the information to such 
users in the manner appropriate for that user. For example, if a destination user has 
access to a computer connection, a PCR can be forwarded to the user as an object or as 
email. In this situation, the appropriate EMCC module for the user will display the 

10 PCR information to the user. Alternately, if the user has a communication device such 
as a pager or a phone, the RD module can convert the information from the PCR into an 
appropriate alphanumeric or spoken format so that the user can receive the information 
on their communication device. 

Thus, the EMCC system provides a variety of advantages over prior 

15 systems. Since the EMCC system guides providers through the process of specifying 
referrals and treatments that can be automatically authorized, the providers can 
promptly receive payment without the uncertainties and delays associated with prior 
systems. Conversely, the automatic approval of referrals and treatments performed by 
*the EMCC system frees insurance plans and/or UM groups from manual review of 

20 claims and authorization requests. Since providers are guided through the process of 
treatments and making referrals, the EMCC system can provide point-of-care protocols 
and sophisticated disease management. In addition, combining together all information 
related to a patient, including demographic, medical history and medical treatment 
information, provides various advantages. The combination of all information together 

25 eliminates the need to do many types of audits which are needed to ensure consistency 
across various disparate data stores. Moreover, since information is electronically 
transferred, the EMCC system eliminates redundant specification of information which 
is time-consuming, annoying, and subject to input error. Finally, the EMCC system can 
provide instantaneous electronic notice to users interested in various types of 

30 information, such as all referrals from a particular provider or the providing of a 
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particular type of service by any provider. Those skilled in the art will appreciate that 
these and analogous EMCC modules can be used by any type of provider, including 
solo practitioner doctors, groups of doctors working together, managed care 
organizations, hospitals, clinics, laboratories, pharmacies, alternative medical care 
5 providers, rehabilitation centers, etc. In addition, those skilled in the art will appreciate 
that some embodiments of the EMCC system can be used to pre-authorize referrals and 
services before the referral is made or the service is performed, while other 
embodiments may only allow the automatic authorization to be determined after the 
referral is made or the service is performed. 

10 Referring now to Figure 1, an embodiment of the EMCC system 100 is 

described. The EMCC system includes an EMCC Server 110 which coordinates the 
activities of various EMCC modules and which facilitates the transfer of electronic 
PCRs and other information between these modules. When a person first seeks care, 
they will typically go to their primary care provider. The primary care provider will use 

15 a Gatekeeper module 105 to determine eligibility of the patient and to review the 
medical history of the patient. The Gatekeeper module will then be used to refer the 
patient to an authorized performing provider who will perform medical services, with 
the referral indicating the types of services which are authorized to be performed. 

If a referral to a hospital for admission is authorized, the Gatekeeper 

20 module and/or the EMCC Server will transmit the corresponding electronic PCR to a 
Hospital module 125. If an authorized referral is not for a hospital admission, the 
Gatekeeper and/or the EMCC Server will instead transmit the electronic PCR to a 
Performing Provider (PP) module 120 for the specified performing provider. However, 
if the. user of the Gatekeeper module specified a referral which could not be 

25 automatically authorized by the EMCC system, the Gatekeeper module and/or the 
- EMCC Server instead transmit the electronic PCR as a request for authorization to an 
Authorization module 115 of a user at the appropriate review level. This review user 
can then promptly authorize, modify, or deny the referral and forward an authorized 
electronic PCR to the appropriate PP or Hospital module for the performing provider. 
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When the patient seeks care at the specified performing provider, it is not 
necessary to re-enter . patient information or re-verify patient eligibility since the 
electronic PCR contains this information. Instead, the referral information in the PCR 
can be used by the PP or Hospital module to guide the performing provider through the 
5 process of specifying, diagnosis and service codes which are authorized for specified 
payments. After services are provided or a patient is discharged, the PP or Hospital 
module and/or the EMCC Server transmit the authorized updated electronic PCR to the 
Paylist module 135 to initiate payment. 

Alternately, if a performing provider chooses diagnosis or service codes 

10 which cannot be automatically authorized, the PP or Hospital module and/or EMCC 
Server transmit the electronic PCR as a request for payment to the Adjudication module 
130 for manual authorization, modification, or denial of payment for the services. After 
the electronic PCR is updated with a manually authorized payment amount, the PCR is 
then forwarded to the Paylist module. When the Paylist module receives an electronic 

15 . PCR that is authorized for a specified payment amount, the electronic PCR is 
automatically processed and payment is immediately forwarded (electronically or 
otherwise) to the appropriate performing and referring providers. 

As an illustrative example, consider the case of a person named Paul 
' Anderson seeking medical care from his primary care provider. Dr. Ted Smith. When 

20 Mr. Anderson initiates ..a visit to Dr. Smith's office, a user at the office invokes a 
Gatekeeper module to record the encounter and guide the initial consultation. The user 
can access the Gatekeeper module in a variety of ways. For example, the Gatekeeper 
module could be executed on a local computer at the user's location or on a central 
EMCC Server. If the Gatekeeper module executes on a local computer, it can retrieve 

25 information from an EMCC Server via a network or modem connection or it can 
retrieve information that is stored locally on the local computer. -Alternately, the 
Gatekeeper module can execute on the EMCC Server, and the user can access the 
module via a local computer or a thin client such as an EMCC terminal. Either standard 
connection mechanisms {e.g., a web browser or telnet application) or custom EMCC 
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connection mechanisms can be used. For the purposes of the illustrative example, the 
details of the Gatekeeper module execution are not significant. 

Referring now to Figure 2. an example of a Gatekeeper user interface 
(UI) screen 200 is displayed. When the user first begins the session with the 
5 Gatekeeper module, they are presented with a list of pending PCRs that have been 
created but not completed. As shown in Figure 2. each of the PCRs has a unique PCR 
identifier, and the current display shows the name of the insurance plan and the member 
identifier for the patient, the date that the PCR was created, an urgency level indicating 
how quickly care must be provided, and a review level indicating the appropriate types 

10 of people to review the referral and services represented by the PCR. These PCRs (and 
other information) can be retrieved by the Gatekeeper module in a variety of ways. For 
example, the relevant PCRs for this user's location could be stored on a local computer, 
or all PCRs could instead be stored on a central EMCC Server and retrieved by EMCC 
modules as needed. In the illustrative example, all PCRs are stored on a central EMCC 

15 Server. If a PCR already existed for this encounter/the PCR would be displayed as 
pending and the user could select the PCR. For example, the user might have partially 
created the PCR and then switched to another task before returning to the Gatekeeper 
module to complete the PCR. 

Since the visit by Mr. Anderson is a beginning of a new encounter and 

20 thus has no pending PCR. the user of the Gatekeeper module instead selects the Create 
New Patient Claim Request button on the screen. After selecting this action. UI screen 
300 is displayed to the user as shown in Figure 3. As indicated, the user has now 
entered the Create/Edit Patient Claim Records portion of the UI. with the first of eight 
actions related to creating a new PCR being to identify the insurance plan member 

25 information for the patient. As part of creating a new PCR. the EMCC system 
automatically assigns a unique identifier for the new PCR and the current date is 
inserted in the PCR. A list of possible members is presented to the user, and the user 
scrolls or searches through the list until the entry for Paul Anderson is located. This 
entry indicates Mr. Anderson's insurance plan, plan member ID. primary care provider, 

30 and the provider code for the primary care provider. 
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In the current default mode, the Gatekeeper module displays only that 
information which is appropriate under the current circumstances. For example, if the 
only two doctors at this office are Ted Smith and Jan Wu. only insurance plan member 
information for members which have one; of these doctors as their primary care provider 
5 will be listed, rather than listing all members of all possible insurance plans. If a 
member listing for Paul Anderson cannot be located in the default view, the user can 
select the Show . All button to see the member listing for all known insurance plan 
members. Alternately, the user could manually specify the patient information and 
attempt to verify eligibility. In addition, the user can at any time select the Cancel 

10 button to abort the current transaction and discard the information that has been 
previously entered, or can save the information that has been currently entered for later 
use by selecting the Make Pending button. Since the member listing for Mr. Anderson 
is displayed, the user selects the displayed entry and then selects the View 
Eligibility/Information button to see additional information. 

15 Referring now to UI screen 400 shown in Figure 4, this screen shows 

patient eligibility and other information for Mr. Anderson. A variety of patient 
information can be displayed, including information about when the eligibility of the 
patient as a member of the insurance plan was last automatically verified. When the 
"user is finished reviewing the information on the screen, the user selects the Done 
. 20 button to return to screen 300. and then with the entry for Mr. Anderson selected the 
user selects the Done button on that screen to continue with the PCR creation. If 
information displayed on UI screen 400 had required further investigation, additional 
information could have been retrieved from the EMCC Server using other EMCC 
system functionality (not shown). 

25 After selecting the entry for Mr. Anderson, the Gatekeeper module 

continues to UI screen 500, shown on Figure 5. Note that the patient name and member 
ID were added to the PCR after the member entrv was selected on UI screen 400. with a 
PCR-specific suffix added to the base member ID. Screen 500 allows the user to 
specify a referral history for the current PCR if there have been previous encounters 

30 related to the current encounter. Various other PCRs for the current patient are 
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displayed in the referral history screen, with information displayed indicating the 
problems to which the PCRs -relate. The two PCRs shown indicate that Mr. Anderson 
was treated for circulation problems approximately three months ago, and that three 
days ago he was treated for heart problems. Since the current encounter is related to 
5 continuing heart problems, PCR 000151 from three days ago is related history for the 
current PCR. Thus, the user selects the 000151 PCR and then selects the Associate 
button so that the two PCRs are associated as being related. When the user is finished, 
they select the Done button to continue to the next screen. 

After the user has specified the referral history for the current PCR, the 

10 Gatekeeper module continues to UI screen 600 shown on Figure 6 to display a list of 
providers. The providers displayed are those which the EMCC system can 
automatically authorize to make referrals for this patient based on the insurance plan 
and the past treatment history from associated PCRs. For example, when a patient first 
seeks treatment, it is possible that only a doctor may be authorized to refer the patient 

1 5 for additional treatment. However, after previous treatment by a doctor and continuing 
patient problems, a nurse practitioner may then be authorized to make a referral for later 
visit. The determination of the providers who can be automatically authorized by the 
EMCC system can be performed in a variety of ways. For example, different 
combinations of insurance plans and patients may have unique lists of providers that 

20 were previously specified as authorized to make referrals. Alternately, the EMCC 
system may be able to calculate which providers are authorized in a given situation, 
considering factors such as insurance plan contract details, past treatments, etc. 

Typically, the primary care "provider for a patient will be the referring 
provider. In this situation, however. Dr. Smith is unavailable and Dr. Hilter is seeing 

25 his patients. Thus, Dr. Sally Hilter is selected as the referring provider. If the user 
wished to view additional information about a displayed provider, this could be 
accomplished by using the View Additional Information button with the entry for that 
provider selected. Although UI screen 600 initially displays only those providers who 
can be automatically authorized to make a referral, it is also possible for the user of the 

30 Gatekeeper module to choose another provider. If the user selects the Show All button 
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to see all possible providers and then chooses someone other than one of the three 
automatically authorizable choices, the referral process will continue but there is no 
guarantee that the resulting referral will later be authorized and compensated. After 
selecting the entry for Dr. Hiker, the user selects the Done button to continue to the next 
5 screen. 

After the referring provider is selected, the Gatekeeper module continues 
to UI screen 700 shown in Figure 7. UI screen 700 displays the list of providers who 
can be automatically authorized to receive the referral from Dr. Hilter to treat 
Mr. Anderson by performing one or more medical services. If the user would like to 

10 return to UI screen 600. the user can select the Previous Screen button shown. If so. the 
Gatekeeper module would return to UI screen 600 with the entry for Dr. Hilter selected 
since she is currently specified as the referring provider. As with the list of referring 
providers on screen 600, the current list of performing providers are determined based 
on the previous selections made, such as insurance plan, member, referral history and 

15 referring provider. Since the past medical treatment indicated by the associated PGR 
was related to heart problems, many of the performing providers who can be 
automatically authorized for the current referral may be cardiologists. Note also that a 
self-referral is allowed at the current time. Thus, if the initial consultation by Dr. Hilter 
* had indicated that additional treatment of a general nature by herself was a preferred 

20 course of action, a self-referral could be used to automatically authorize an extended 
course of treatment. In this situation, however. Mr. Anderson's continuing heart 
problems are best treated by a cardiologist, so the user of the Gatekeeper module selects 
Dr. Roberto Mendez as the performing provider and continues to the next screen. 

The Gatekeeper module continues to UI screen 800 shown on Figure 8. 

25 This screen allows the user to identify one or more referral bases for referring the 
patient to the performing provider. As with previous screens, the referral bases listed 
can be automatically authorized based on the combination of previous selections made, 
including the performing provider. These referral bases describe patient problems at a 
high level, such as a problem with a major bodily system. While Dr. Hilter does not 

30 have the necessary cardiological expertise to make precise diagnoses, she suspects that 
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Mr. Anderson may be having problems related to arrhythmia and/or a heart valve 
disorder. Thus, the user of the Gatekeeper module selects referral bases entries related 
to those problems and then selects the Done button to continue. 

The Gatekeeper module then continues to UI screen 900 shown on 
5 Figure 9. where a list of types of facilities for the referral treatment are shown. These 
listed facilities can be automatically authorized based on the combination of previous 
selections made, and the user selects a physician's office as the appropriate facility type. 
The user then continues to the next screen by selecting the Done button. 

After selecting the type of facility, the Gatekeeper module continues to 

10 UI screen 1000 shown on Figure 10. This screen allows the user to specify one or more 
suggestions for types of referral treatments to be performed by the performing provider. 
As with the referral bases, the referral treatment type suggestions are often at a high 
level rather than a highly particularized service. In this case. Dr. Hilter believes that lab 
tests and diagnostic X-rays may be the best course of continued treatment. As before, 

15 the treatment type suggestions shown can be automatically authorized based on the 
previous selections made. After selecting the referral treatment type suggestions, the 
user selects the Done button to continue to the next screen. 

The Gatekeeper module then continues to UI screen 1100 shown in 
Figure 1 1 . UI screen 1 100 allows the user to specify an urgency for the current referral. 

20 Since Mr. Anderson's continuing heart problems need immediate attention, but do not 
constitute an emergency, the user selects Urgent as the urgency for the referral. Note 
that the Gatekeeper module can automatically add information to the PCR. In the 
current example, the Gatekeeper module has determined based on the selections made 
that a UR review level should be assigned to this PCR, and automatically added this 

25 information. If manual review of the PCR is required, this review level will determine 
which users can manually authorize the referral. Even if the PCR can be automatically 
authorized, some users may desire notification that the referral was made. The review 
level can indicate any user in a specified group (e.g., UR nurses), or particular users 
(e.g., a case manager or department head). After making the selection, the user has 
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completed the creation of the PCR. Those skilled in the an will appreciate that other 
types of information could also be specified for the referral. 

The Gatekeeper module then continues to UI screen 1200 shown in 
Figure 12. This screen provides a summary of the information in the current PCR. 
5 After reviewing the displayed information, the user must select an action to be taken 
with the PCR. As previously indicated, the user can return the PCR to the current list of 
pending PCRs by selecting the Make Pending burton. Alternately, the user can decline 
to make the referral and can select the Delete button to remove the PCR. If the user 
wishes to continue the referral, however, the user will select one of the two Submit 
. 10 buttons. 

If the user wishes to create additional PCRs for this patient, the user will 
select the Submit And Create Additional Patient Claim Record For Current Patient 
button. For example, while Mr. Anderson's primary motivation for visiting Dr. Hilter 
may be his continuing heart problems, Mr. Anderson may also have an unrelated 

15 medical condition such as a cut on his leg. If so, the EMCC system can create a new 
PCR containing the appropriate patient information, and then return the user to UI 
screen 500 with the new PCR. This removes the need to re-specify patient information 
and re-verify patient eligibility. If the user instead wishes to submit this referral and 
'return to UI screen 200. the user will select the Submit button. 

20 When the user selects either Submit button, the PCR will be forwarded 

to the appropriate recipients. If the user has specified a referral that can be 
automatically authorized, the EMCC system authorizes the referral and transmits the 
PCR to the performing provider Dr. Mendez. However, if the referral could not be 
automatically authorized, the PCR is instead transmitted to one or more users at the 

25 appropriate review level for manual authorization or denial of the requested referral. 

Since the referral is automatically authorized, the PCR is transmitted to 
Dr. Mendez. When the patient arrives at Dr. Mendez's office, a user at that office uses 
a Performing Provider (PP) module to process the referral. The user will first view a UI 
screen, similar to UI screen 200, to display the pending PCRs for Dr. Mendez. When 

30 the user selects the PCR for Mr. Anderson that was electronically transmitted to the PP 
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module, the PP module then continues to UI screen 1300 shown in Figure 13. This 
screen displays ICD-9 diagnosis codes for Mr. Anderson that can he automatically 
authorized by the EiVlCC system based on the referral. If the user selects one or more of 
the displayed diagnosis codes and Dr. Mendez then performs a corresponding service 
5 that can also be automatically authorized. Dr. Mendez will be guaranteed to receive 
payment for the service. After examining Mr. Anderson. Dr. Mendez diagnoses that 
Mr. Anderson suffers from pulmonary heart disease and may have a congenital heart 
anomaly. The user of the PP module selects diagnosis codes related to these diagnoses, 
and selects the Done button to continue. 

10 The PP module continues to UI screen 1400, shown on Figure 14, to 

display CPT service codes for services that Dr. Mendez can perform, with the displayed 
codes being only those which can be automatically authorized, based on the referral and 
the selected diagnosis codes. After the user selects an entry for an extended office visit, 
the user selects the Done button to continue to the next screen. 

15 The PP module then continues to UI screen 1500, shown in Figure 15. 

This screen allows the PP module user to review the updated PCR for Mr. Anderson. If 
the diagnosis and provision of services is complete at this time, the user can select the 
Submit button to submit the PCR for payment. Alternately, the user can select the 
* Make Pending button if further treatment will occur or if the user wishes to review the 

20 selected diagnosis and service codes at a later time. 

If the PCR can be automatically authorized for payment, the EMCC 
system authorizes the services and the PCR is forwarded to a Pay list module for 
immediate payment. Alternately, if the user has selected diagnosis or service codes 
which cannot be automatically authorized, the PCR is forwarded to one or more users 

25 for manual adjudication of whether the services will be compensated, and if so, at what 
amount. Since Mr. Anderson's claim could be automatically authorized, even before 
the PCR is submitted the PP module can determine and display the amount of payment 
that will be received by Dr. Mendez. 

In this manner, the Gatekeeper and PP modules can guide providers 

30 through the process of referring and treating patients in such a way that the treatments 
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and referrals can be automatically authorized and are immediately reimbursable at a 
specified payment amount. The EMCC system thus greatly reduces the need for 
manual review of patient treatment and referral claims. 

Figure 16 shows an exemplary embodiment of an EMCC system 
5 consisting of an EMCC Server 1600 communicating with a variety of EMCC clients 
1650. 1660. and 1670 via a communication means such as a network 1655. In the 
exemplary embodiment, all EMCC modules execute on the EMCC Server, with the 
EMCC clients receiving information to be displayed to the user and returning user input 
information. Those skilled in the art will appreciate that multiple copies of a module 
10 may be executing at the same time on the EMCC Server, or that multiple clients may 
share a single executing copy of a module. Those skilled in the art will also appreciate 
that the EMCC clients could be mere display terminals connected to a server computer, 
or instead could be computers that execute EMCC modules and store EMCC 
information locally. 

15 Each EMCC client has an EMCC interface that allows the client to 

invoke one or more EMCC modules on the EMCC Server. The EMCC modules 
include a Gatekeeper module 1631, a PP module 1632, a Hospital module 1633. an 
Authorization module 1634, an . Adjudication module 1635. a Remote Distribution 
•module 1636. and a Paylist module 1637. The modules perform the functions described 

20 in reference to Figure 1, with the Remote: Distribution module facilitating the transfer of 
information between the other modules. The EMCC Server also includes a CPU 1610, 
a memory 1630. and input/output devices 1620 including a network connection 1622, a 
computer-readable media drive 1623 and a display 1624. 

The EMCC modules are loaded into memory and execute on the CPU. 

25 While executing, the modules retrieve and process a variety of information. In the 
exemplary embodiment, a storage device 1640 serves as a central repository for storing 
a variety of medical information. Medical information 1680 includes information which 
will typically be retrieved from sources outside the EMCC system (e.g., insurance plan 
.computers), either before or during execution of the EMCC modules. Medical 

30 information 1680 includes reference information 1681 (e.g., ICD-9 diagnosis codes and 
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CPT service codes), information about providers 1682 (e.g., specialties, affiliations and 
previous disciplinary measures) and facilities 1685, and information about insurance 
plans such as contractually covered benefits and terms 1683 and members 1684. The 
storage device also stores medical information created by or entered into the EMCC 
5 system, such as PCRs 1641 and patient medical histories 1642. 

In addition to medical information, storage device 1640 stores EMCC- 
specific system information 1690 which is used by the -EMCC system to create PCRs 
and to automatically authorize referrals and services. The EMCC-specific system 
information includes information created to allow the EMCC modules to categorize 
10 patients and users (i.e.* patient risk factors 1692 and review levels 1693). to distribute 
information to users (i.e.* user distribution information 1694). and to identify referrals 
and services which can be automatically authorized (i.e., referral bases 1695. referral 
treatment suggestion types 1696, referral urgency levels 1697. and EMCC mapping 
information 1699). 

15 In the exemplary embodiment, the referral bases are general reasons for a 

referral described in a medical provider's vernacular, such as problems related to one of 
the major bodily systems. Since a provider at an initial consultation will often not have 
the time or expertise to make a precise diagnosis, the referral bases provide a general 
•description that may encompass many varied diagnosis codes. Similarly, the referral 

20 . treatment suggestion types are general directions to a performing provider, at a level 
appropriate for a referring provider that has not made a specific diagnosis. Typically, 
multiple service codes can be authorized for a single choice for a referring provider, a 
performing provider, a referral basis, a referral treatment suggestion type, and a referral 
urgency level. 

25 The EMCC mapping information allows the EMCC system to determine 

choices for a type of information (e.g., a performing provider) such that a resulting 
referral using the choice can be automatically authorized for payment based on 
previously specified information (e.g., insurance plan member information, past related 
treatments, or the referring provider). Those skilled in the art will appreciate that the 

30 EMCC mapping information can be provided in a variety of formats, including having a 
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list of pre-specified choices for each type of information and for each combination of 
choices for previous selections. 

The user distribution information can be used by the Remote 
Distribution module to forward information to the correct users with the correct format. 
5 For example, the user distribution information may keep tracks of all UR nurses so that 
manual authorization of a PCR by a UR nurse is limited to the appropriate individuals. 
Alternately, the user distribution information may track that a particular user is to 
receive PCR information and other messages via a specified pager number. 

In the exemplary embodiment, the EMCC modules executing on the 

10 EMCC Server receive input information from EMCC clients, retrieve information from 
the various information stores on the storage device, store information that is input by 
users in the PCRs, and use remote distribution information to contact specific users or 
to notify other EMCC modules that information is available. The workings of the 
various EMCC modules will be described in greater detail in relation to Figures 1 7 

15 through 25. Those skilled in the an will appreciate that the EMCC Server and the 
EMCC clients are merely illustrative and are not intended to limit the scope of the 
present invention. Other embodiments may contain additional components or may lack 
some illustrated components, and the present invention may accordingly be practiced 
' with other computer system configurations. 

20 Figures 17A and 17B are flow diagrams of an embodiment of the 

Gatekeeper routine 1700. The Gatekeeper routine enables a provider to make a medical 
referral for a patient that is automatically authorized. The Gatekeeper routine is 
executed upon a provider's initial encounter with a patient (e.g., at a primary care 
provider's office), and can also be executed at a later point during an encounter in order 

25 to create additional referrals. The routine selects a new or existing PCR. and then if 
necessary, it identifies insurance plan member information for the patient, verifies 
patient eligibility, and associates the PCR with other related PCRs. The routine then 
specifies referral information including a referring and performing provider, a referral 
basis, a type of facility for the referral, a referral treatment type suggestion, and an 
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urgency of treatment, and determines a review level and patient risk factors for the 
referral. 

The routine begins at step 1705 by retrieving from the EMCC Server all 
pending PCRs that are queued for this Gatekeeper routine. In the exemplary 
5 embodiment, all PCRs are stored at the EMCC Server. Thus, each Gatekeeper routine 
could have a separate queue holding pending PCRs for that routine, or all PCRs could 
be stored together and could contain information identifying the routine with which the 
PCR is currently associated. After retrieving the PCRs. the routine displays the records 
to the user of the routine, and receives in step 1710 a user selection to either create a 

1 0 new PCR or to edit an existing PCR. The routine continues to step 1 71 5 to determine if 
the selection was to create a new PCR. If not. the routine continues to step 1 740 to 
retrieve the existing PCR that was indicated. 

If the selection was to create a new PCR. the routine continues to step 
1720 to receive a user indication of the insurance plan for which the patient is a 

15 member. In the exemplary embodiment, the routine retrieves insurance plan member 
information from the EMCC Server and displays possible members to the user. The list 
of members may be limited to only those members for whom the provider is their 
primary care provider, or may include all possible members. If an entry for the patient 
*is displayed, the user of the routine can select the displayed member entry in step 1 720. 

20 Alternately, the user can attempt to locate insurance plan information for the patient by 
expanding the list of displayed members {e.g., to all possible members), or by manual 
overriding the EMCC system and specifying insurance plan information. 

After an insurance plan member selection is made in step 1720, the 
routine continues to step 1725 to verify eligibility of the patient. In the exemplary 

25 embodiment, only eligible patients are displayed in the initial list of member 
information displayed to the user. Thus, it may not be necessary to verify patient 
eligibility, if a selection was made from the initial list, although the user of the 
Gatekeeper routine may still wish to determine information such as when eligibility of 
the patient was last verified by the insurance plan. After verifying patient eligibility, the 

30 routine checks in step 1 730 whether the patient was verified to be eligible. If the patient 
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is not eligible, and thus authorization for any treatments or referrals cannot be obtained, 
the routine returns to step 1 705. 

If the patient is determined to be eligible in step 1730. however, the 
routine continues to step 1735 where a new blank PCR is created to hold information 
5 for the current encounter. The routine can automatically add information to the PCR 
such as a unique PCR identifier and the current date. In the exemplary embodiment, the 
PCR is given a status which is initially set to "Authorized^ and which can be modified 
by the various EMCC modules. In addition, in the exemplary embodiment once the 
PCR is created it will always be associated with one of the EMCC modules. When the 

10 PCR is not currently in use by its associated module, it will be considered to be in a 
queue for that module whether the PCR is actually stored on the EMCC Server or on a 
local computer and whether the PCRs associated with a particular module are actually 
stored apart from the PCRs from other modules. 

After step 1740 or step 1735. the routine continues to step 1745 to 

15 optionally associate the current PCR with other previously created PCRs. Two or more 
PCRs can be associated when they are related based on the patient's reasons for seeking 
treatment and the treatment received. For example, if a patient is having continuing 
heart problems then the PCRs for past encounters related to treating these heart 
problems would be associated with a current PCR for the same problem. In the 

20 exemplary embodiment, a patient can automatically specify that a series of successively 
created PCRs be associated together, or a list of previously created PCRs can be 
displayed and the user can select one or more displayed PCRs to associate with the 
current PCR. The routine then specifies information for the referral by executing 
subroutine 1750. This referral information will include a referring provider, a 

25 performing provider, a referral basis, a type of facility, a referral treatment type 
suggestion, and an urgency of treatment. Each specification will include presenting the 
user with choices for which the resulting referral can be automatically authorized based 
on the previous specifications. 

As with the list of members, the user can choose to manually override 

30 the EMCC system and specify a referral information choice that cannot be 
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automatically authorized. If so. the current status of the PCR will be set to be 
"Unauthorized." In the exemplary embodiment, alter a PCR selection is manually 
overridden the EMCC system no longer tries to limit choices for later selections to 
those which can be automatically authorized. Instead, all possible choices are listed for 
5 these later selections, and authorization for the resulting referral will need to be 
manually specified after the referral creation is complete. 

After the referral information is supplied, the routine continues to step 
1 760 to determine if the user wishes to submit the claim and thus send the PCR to the 
next appropriate EMCC module. If the* user does not wish to submit the PCR. the 

10 routine continues to step 1762 where the status of the PCR is reset to ensure that it is 
not ''Unauthorized/' As mentioned above, the PCR status may have become 
"Unauthorized" based on selections made when executing subroutine 1750 and step 
1720. Since the PCR is not going to be submitted, it will become a pending PCR that 
will be retrieved the next time step 1 705 is executed. When the PCR is later selected as 

15a pending PCR. the user will have the option of modifying the selections so that the 
PCR can be automatically authorized. If the manually overriden selections are not 
appropriately modified, the status of the PCR will return to "Unauthorized" at that time. 

After resetting the PCR status in step 1 762, the routine continues to step 
*1764 to invoke the Remote Distribution subroutine and thus place the PCR in the 

20 appropriate pending module queue or transmitting it to the appropriate users. Those 
skilled in the an will appreciate that the Remote Distribution subroutine could send the 
PCR between routines in a variety of ways. For example, if all PCRs are stored 
together on the EMCC Server, it may only be necessary to change the PCR association 
so that another routine becomes currently associated with that PCR. Alternately, a PCR 

25 could be electronically transmitted to another routine as a message or an object, or a 
message could be transmitted to the other routine to indicate that the PCR is stored at a 
specified location. 

If the user instead determines in step 1 760 to submit the PCR. the routine 
continues to step 1765 to determine if the PCR status is "Unauthorized." If so, the 
30 routine continues to step 1770 to invoke the Remote Distribution subroutine to send the 
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PCR to an Authorization module for manual authorization. If the PCR status is not 
"Unauthorized." however, the PCR can be automatically authorized and so the routine 
instead continues to step 1 775 to invoke the Remote Distribution subroutine to send the 
PCR to the PP module for the indicated performing provider. After step 1770 or 1775, 
5 the routine continues to step 1780 to. invoke the Remote Distribution subroutine to 
optionally send the PCR to any users interested in. the PCR. For example, a case 
manager may wish to review all referrals made by a particular provider, even if the 
referrals are automatically authorized, or may instead wish to review all referrals for a 
certain type of referral basis regardless of the referring provider. 

10 After step 1780 or 1764, the routine continues to step 1786 to determine 

if additional PCRs for this patient should be created. If not, the routine returns to step 
1705, and if so the routine continues to step 1788 where a new blank PCR is created for 
the patient with the referring provider and patient information specified. After step 
1788, the routine returns to step 1750 to designate the appropriate referral information. 

15 Those skilled in the art will appreciate that the same functions can be accomplished 
with a variety of modifications to the routine, such as including multiple referrals within 
a single PCR or associating a PCR with PCRs for other members. 

Figure 1 8 is a flow diagram of an embodiment of the Designate Referral 
information subroutine 1 750. The subroutine receives a PCR which has insurance plan 

20 member information specified and optionally other PCRs associated, and allows the 
user to specify a referring provider, a performing provider, a referral basis, a type of 
facility, a referral treatment type suggestion, and an urgency of treatment level. The 
subroutine also determines patient risk factors and a manual review level for the PCR. 
The subroutine begins in step 1805 where , a PCR is received. The subroutine then 

25 continues to step 1815 to compile a history of past treatments related to the current 
referral based on the current PCR and its associated PCRs. 

After retrieving and processing this previously specified information, the 
subroutine then specifies the referral information. The subroutine continues to step 
1825 where the referring provider who will make the referral is selected by invoking the 

30 Select An Instance Of Specified Type Of Information Based On Specified Context Of 
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Past Selections subroutine 1900. Subroutine 1900 will be invoked with the specified 
type of information to be selected being a referring provider and with the specified 
context of past selections being the selections previously made for this PCR (i.e.. the 
insurance plan member information and any past related treatments from associated 
5 PCRs). Execution of subroutine 1900 will present the user with a list of choices, with 
any of the choices such that the EMCC system can automatically authorize the choice as 
the referring provider for the referral. These authorizable choices will vary based on the 
context of past selections. As with the insurance plan member information, the user can 
choose to manually override the list of authorizable choices and specify a choice which 
10 is not automatically authorizable. If so. the status of the PCR will be set to 
^Unauthorized." 

After selecting a referring provider in step 1825, - the subroutine 
continues to step 1835 where the performing provider who will receive the referral is 
selected by invoking subroutine 1900. Subroutine 1900 will be invoked similarly in 

15 . step 1835 to that of step 1825, with the specified type of information to be selected 
being a performing provider and with the specified context of past selections again 
being the selections previously made for this PCR (i.e., the insurance plan member 
information, any past related treatments from associated PCRs, and the referring 
provider). Execution of subroutine 1900 will allow the user to specify a performing 

20 provider by selecting an automatically authorizable choice based on past selections, or 
by manually overriding the system and specifying an alternate choice. The subroutine 
then continues to step 1 840 to similarly select a referral basis which indicates why the 
referral was made. This is accomplished by invoking subroutine 1900. with the 
specified context of past selections including the same factors as before with the 

25 addition of the selected performing provider. After step 1840, the subroutine continues 
to step 1 845 to similarly select a type of facility for the.referral based on past selections 
including the performing provider, and to step 1850 to * similarly select a referral 
treatment type suggestion based on past selections including the type of facility. While 
the illustrated routine allows only a single performing provider, referral -basis, type of 

30 facility and referral treatment type suggestion for each PCR, those skilled in the art will 
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appreciate that multiple choices for one or more of these types of information could be 
selected, with choices for subsequent types of referral information made either for each 
of the earlier choices or for the combination of earlier choices. 

The subroutine then continues to step 1 855 to allow the user to select an 
5 urgency of treatment level for the referral represented by the PCR. The urgency level 
can be used in a variety of ways, such as to prioritize PCRs in a list of pending PCRs or 
to prioritize transmission of a PCR or a related message. The subroutine then continues 
to step 1860 where patient risk factors associated with the current selections are 
determined and added to the PCR. In the exemplary embodiment, the user selects 

10 patient risk factors from a list appropriate for the referral basis and referral treatment 
type suggestion. Alternately, the EMCC system could automatically determine this 
information, such as by comparing the appropriate list to patient risk factors in a 
previously specified patient medical history. In step 1865, a manual review level is next 
determined for the PCR. This review level will determine which users are allowed to 

15 manually authorize a PCR with an "Unauthorized^ status. In some embodiments, the 
review level can also be used to specify one or more users which are interested in 
receiving information about the current PCR, regardless of whether the corresponding 
referral is automatically authorized. The subroutine continues to step 1870 to add the 
" urgency level, the determined risk factors and the manual review level to the PCR. In 

20 step 1875 the subroutine returns. Those skilled in the art will appreciate that some steps 
could be conducted in a different order, and that the steps could -be performed in a 
variety of ways. For example, some embodiments may not determine a review level 
unless an unauthorized selection is made. Alternately, other embodiments may 
automatically determine an urgency level based on factors such as the specified referral 

25 basis, performing provider, type of facility, and referred treatment type suggestions. 

Figure 19 is a flow diagram of an embodiment of the Select An Instance 
Of Specified Type Of Information Based On Specified Context Of Past Selection 
subroutine 1900. This subroutine is invoked multiple times, with each invocation 
including a type of information to be selected (e.g.. a referring provider) and a context 

30 of past selections (e.g.. the insurance plan member selection and past related treatment 
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from associated PCRs). The subroutine first determines appropriate choices for the 
specified type of information based on the specified context such that the EMCC system 
- can automatically authorize a resulting referral which includes one of the choices. The 
subroutine then displays the choices to the user, allows the user to select a choice or 
5 manually specify an alternate choice, and adds the specified choice to the PCR. 

The subroutine begins in step 1905 where a PCR and a history of related 
past treatment is received, along with a specified type of information to be selected and 
a specified context of past selections. Alternately, the subroutine could examine the 
PCR to retrieve the previously specified information and to determine the next type of 

10 information which needs to be selected. The subroutine then continues to step 1915 to 
identify choices for the specified type of information which can be automatically 
authorized based on the previous selections for the PCR. As described previously, the 
identification of these choices can be performed in a variety of ways, such as by pre- 
specifying authorized choices for a type of information based on various combinations 

15 of choices for types of previously specified information. 

The subroutine * then continues to step 1920 to determine if there is 
already a choice that was previously specified in the PCR for the current type of 
information, and if so. whether the choice remains satisfactory to the user. Such a 
choice may exist if a user makes a selection, continues to the next user selection, and 

20 then decides to return and review the previous selection. Alternately, during a previous 
execution of the Gatekeeper routine, the user may have made a selection for this type of 
referral information for this PCR ? but chose not to submit the PCR. ' In that case, the 
PCR would join the list of pending PCRs for that routine, and when the PCR is later 
selected in step 1710 the routine may be re-executed with the PCR. Therefore, when 

25 subroutine 1900 is invoked with a PCR, the PCR may already have a selected choice for 
the specified type of referral information. Moreover, it is also possible that the status of 
whether the choice can be automatically authorized by the EMCC system has changed 
since the' choice was first made. Since the subroutine is re-executed; however, the 
current status of the choice can be reflected. Thus, if a previous choice already exists, 

30 the choice and the current automatic authorization status of the choice is displayed to 
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the user in step 1920. allowing the user to retain the choice or to select a different 
choice. If this previous choice cannot be automatically authorized at the current time 
and it is retained by the user, the status of the PCR will become 'Unauthorized/ 

If it is determined in step 1 920 that the PCR has a selected choice for the 

5 specified type of referral information that is satisfactory to the user, the subroutine 
continues to step 1940. If the PCR does not have a selected choice or if such a choice is 
not satisfactory, the subroutine allows the user to specify a new choice. If there are a 
large number of choices which can be automatically authorized, however, it can be 
useful for the subroutine to identify the most likely choices for the current selection. 

10 These likely choices can assist the user in selecting a choice, such as by using a likely 
choice as a default or by listing likely choices that can be automatically authorized 
before other choices that can be automatically authorized. Identifying likely choices 
can be performed in a variety of ways (e.g.. using a patient's primary care provider as a 
default for the referring provider selection). In the exemplary embodiment, the 

15 subroutine continues to step 1925 to determine the choices for the specified type of 
information in any associated PCRs so that these choices can be treated as likely 
choices. For example, if an associated PGR referred the patient to a particular 
performing provider, that same performing provider may be selected for the related 
current referral . 

20 • After determining the choicesthat are selected in associated PCRs. the 

subroutine then continues to step 1930 to display the list of choices that can be 
automatically authorized, with the choices from associated PCRs listed first. In the 
' illustrated embodiment, choices which can be automatically authorized are displayed 
differently than, those which require a manual override of the EMCC system, such as by 

25 displaying the manual override choices as grayed out or in a different font. In addition, 
when a selection is made by the user, the selected choice is displayed differently than 
other choices, such as by highlighting or reverse-highlighting the choice. Thus, once 
the user selects a displayed choice, or if a choice was previously selected, the selected 
choice is identified in the display. Alternately, if the user wishes to specify a choice 

30 which cannot be automatically authorized, the user can type the choice or ask the 
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system to display all choices instead of only those which can be automatically 
authorized. 

Once a choice is selected, the user can indicate acceptance of the 
selection in step 1935. such as by selecting a Done button or pressing the Enter key. 
5 After step 1935. or if it was determined in step 1920 that a satisfactory selected value 
was available, the subroutine* continues to step 1940 to determine if the selection made 
is authorized (/.<?., is among those choices identified in step 1915). Jf not. the 
subroutine continues to step 1950 where the PCR status is set to 'Unauthorized/ After 
step 1950, or if it determined in step 1940 that the selection was authorized, the 

10 subroutine continues to step 1960 to add the selected choice to the current PCR. The 
subroutine returns in step 1965. Those skilled in the art will appreciate that there are a 
variety T ways for displaying a group of choices in which some of the choices can be 
automatics! :y authorized and in which others cannot. Rather than displaying only the 
choices which can be automatically authorized, all choices could be initially displayed 

15 with the authorizable choices indicated. Alternately, a default could be selected for one 
or more types of information (e.g., the primary care provider at the location where the 
routine is being executed could be the default referring provider). 

Figures 20A and 20B are flow diagrams of an embodiment of the 
'Remote Distribution subroutine 2000. The subroutine receives a PCR and an indication 

20 . of a destination to receive PCR information, and distributes the PCR or its information 
to the appropriate destination. The subroutine begins in step' 2005 where it receives an 
indication of the PCR and of the destination for information distribution. The 
subroutine continues to step 2010 to create a message which includes the PCR 
information. This message can be created in a variety of forms, such as a textual listing 

25 of all PCR information or merely an indication of the unique PCR identifier that allows 
: the recipient to access the indicated PCR. The subroutine then continues to step 201 5 to 
. check the indicated destination. If it is determined in step 2020 that the destination is 
the current* Gatekeeper routine, the subroutine in step 2025 merely places the PCR in 
the queue for the Gatekeeper module of the referring provider. If it is instead 

30 determined in step 2030 that the destination is an Authorization module, the subroutine 
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determines in step 2035 the appropriate users to review the PCR based on the PCR's 
review level, and in step 2040 sends a message to the Authorization modules for those 
users as well as placing the PCR in the queue for those modules. The subroutine may 
need to both send a message and to place the PGR in a queue because in the exemplar}' 
5 embodiment, some review users (e.g., a UR nurse) may have a networked computer 
executing an Authorization module to retrieve pending PCRs from the EMCC Server 
while other users (e.g.* a doctor) may need to be contacted in other manners such as via 
a pager, cellular phone, or voicemail message. The subroutine will thus transmit the 
PCR information to the review users in the manner appropriate for the user to receive 

10 the information. 

If it is instead determined in step 2045 that the destination is users who 
are interested in the PCR, the subroutine continues to step 2050 to determine the 
interested users. For example, determined users may have been specified when the 
Remote Distribution subroutine was invoked, or may be listed in the PCR. Alternately, 

15 users interested in certain types of information and PCRs may have previously logged 
this interest with the EMCC Server. After the interested users are determined, the 
subroutine continues to step 2055 to send the created message to the determined users. 
If the subroutine instead determines in step 2060 that the destination is the performing 
provider in the PCR and that the performing provider is. a hospital, the subroutine 

20 continues to step 2070 to. place the PCR in a queue for the Hospital module for the 
hospital performing provider. If the subroutine instead determines in step 2075 that the 
destination is a non-hospital performing provider, the subroutine continues to step 2077 
to place the PCR in a queue for the PP module of the non-hospital performing provider. 

If the subroutine instead determines in step 2080 that the destination is 

25 an Adjudication module, the subroutine, continues to step 2082 to determine the 
appropriate users to review the payment request, for the. PCR. As with authorization 
users and interested users, the appropriate users for adjudication can be determined in a 
variety of ways. After determining the appropriate users, the subroutine continues to 
step 2084 to send the message to the users and to place the PCR in the queue for the 

30 determined users" modules. If the subroutine instead determines in step 2086 that the 
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destination is a Paylist module, the subroutine continues to step 2088 to place the PCR 
in the queue for the Paylist module. If the subroutine instead determines that the 
destination indicates those interested in the denial of authorization for a referral, the 
subroutine continues to step 2092 to send a message to the Gatekeeper module for the 
5 referring provider and to the PP module for the performing provider specified in the 
PCR, as well as to any other users interested in PCR authorization denials. If the 
destination does not match any of the previously specified destinations, or after steps 
2025. 2040, 2055. 2070. 2077. 2084. 2088. or 2092. the subroutine returns in step 2094. 

Figure 21 is a How diagram of an embodiment of the Authorization 

.10 routine 2100. The Authorization routine allows a user to review PCR referrals which 
cannot be automatically authorized and to determine whether to authorize them. The 
routine either receives a PCR-related message or retrieves PCRs with pending 
authorization requests, displays the information from a PCR. and allows the user to 
determine whether to authorize, modify or deny the referral represented by the PCR. 

15 The routine begins at step 2105 where it is determined whether the Authorization 
routine has access to a network connection to an EMCC server. If not (e.g., a pager), 
the routine continues to step 2110 where it waits for a message indicating that a PCR is 
to be reviewed. After a message is received, the routine continue., to step 2115 to 
* display PCR-related information stored in the message. After the user has reviewed the 

20 information, the user supplies a command that is received in step 2120. Those skilled in 
the art will appreciate that the Authorization routine can be executed on a variety of 
types of hardware including pagers, cellular phones, personal digital assistants, etc.. and 
that information will be sent to and displayed on these different types of hardware in the 
manner appropriate for that hardware. If the hardware did not allow a user response to 

25 the displayed information (e.g.. a one-way pager in which the user responds via a 
separate telephone), the routine could merely display the received information and skip 
the steps of receiving and responding to a user command. 

If it was instead determined in step 2105 that a network connection 
existed to the EMCC Server, the routine continues to step 2125 to retrieve all PCRs 

30 from the EMCC Server in the queue for this Authorization module. The routine then 
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continues to step 2130 to receive a selection by the user of a displayed PCR. In 
response, the routine in step 2135 displays the information stored in the selected PCR. 
and continues to step 2140 to receive a command from the user. If it is determined in 
step 2145 that the user specified additional information to be displayed (e.g., 
5 information on past treatment history or on a provider), the routine continues to step 
2150 to retrieve and display the requested information from the EMCC Server and then 
returns to step 2140. In the exemplary embodiment, hardware, without a network 
connection to the EMCC Server is allowed to reply to a received PCR, but not to 
request additional information. 

1 0 Thus, if it is determined in step 2 1 45 that the user command in step 2 1 40 

was not to get additional information, the routine continues to step 2155 to determine if 
the user command was to modify the requested referral. If so. the routine continues to 
step 2160 to receive information from the user indicating how to modify the PCR (e.g., 
change the referral treatment type suggestion) and then modifies the PCR as indicated. 

1 5 After step 2 1 60. or if it is instead determined in step 2 1 65 that the user command was to 
authorize the PCR, the routine continues to step 21 70 to reset the PCR status so that it is 
not "Unauthorized. " The routine then continues to step 2175 to invoke the Remote 
Distribution subroutine to send the PCR to the PP module for the performing provider. 
: If it was not determined in step 2 1 65 that the user command was to authorize the PCR. 

20 the routine instead continues to step 2180 to determine if the user command was to deny 
the authorization. If so r the routine continues to step 2185 to invoke the Remote 
Distribution subroutine to notify the referring and performing providers as well as any 
other users who are interested in the denial. If the user command was not to deny the 
authorization request, the routine continues to step 2190 to invoke the Remote 

25 Distribution subroutine to return the PCR to an Authorization module. For example, 
the user of this Authorization module may wish to defer a decision on this PCR until 
later, or to defer a decision to a different user at the same or a higher review level. After 
step 2175. 2185. or 2190, the routine returns to step 2105. 

Figure 22 is a flow diagram of an embodiment of a Performing Provider 

30 (PP) routine 2200. The routine receives PCRs reflecting authorized referrals from either 
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Gatekeeper or Authorization modules, guides a user through specifying diagnoses and 
services which can be automatically authorized, determines the payment to be received 
for automatically authorized services, forwards PCRs with automatically authorized 
services to a Paylist module for payment of the determined payments, and forwards 
5 other PCRs to an Adjudication module for manual determination of an authorized 
payment. 

The routine begins at step 2205 where all PCRs in the queue for the 
current PP module are retrieved from the EMCC server. The routine then continues to 
step 2210 to receive a selection of a displayed PCR from the user. The routine 
10 continues to step 2215 to retrieve additional patient medical history for the patient, such 
as associated PCRs. The routine then continues to step 2225 to invoke subroutine 1900 
to assist the user in selecting for the patient an ICD-9 diagnosis code corresponding to a 
diagnosis made by the provider. Diagnosis codes are indicated for which the routine 
can automatically authorize payment based on the context of previously specified 
15 information (i.e.. the insurance plan, the patient, related past treatment, the referring and 
performing providers, the referral basis, the type of facility, the referral treatment type 
suggestion, and the urgency). 

After selecting a diagnosis code, the routine continues to step 2230 to 
•similarly invoke subroutine 1900 to assist the user in selecting for the patient a CPT 
20 service code corresponding to products or services supplied by the performing provider. 
Service codes are indicated for which the routine can automatically authorize payment 
based on the context of previously specified information, including the selected ICD-9 
diagnosis code. The routine continues to step 2235 to add the selected ICD-9 code and 
CPT codes to the PCR. The routine then continues to step 2240 to determine if there 
25 are additional ICD-9 and CPT codes to be added to the PCR. If so. the routine returns 
. to step 2225. and if not the routine continues to step 2245 to determine if the user 
wishes to submit the current PCR to either the Paylist or Adjudication modules. 

If it is determined in 2245 that the user does not wish to submit the PCR. 
the routine continues to step '2250 to reset the PCR status so that is not "Unauthorized." 
30 The routine then continues to step 2255 to invoke the Remote Distribution subroutine to 
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return the PCR to the queue of pending PCRs for the current PP routine. If it is instead 
determined in step 2245 that the user does wish to submit the PCR, the routine 
continues to step 2260 to determine if the PCR status is "Unauthorized/' If so. the 
routine continues to step 2275 to invoke the Remote Distribution subroutine to send the 
5 PCR to an Adjudication module. If it is instead determined in step 2260 that the PCR 
status is not "Unauthorized." the routine continues to step 2265 to determine the 
payment that will be received for the services indicated by the specified CPT codes. 
The routine then in step 2270 sends the PCR to the Paylist module for immediate 
payment of the determined amount. After steps 2255. 2270, or 2275. the routine returns 
10 to step 2205. 

Those skilled in the art will appreciate that a . variety of types or 
combinations of codes can be used by the PP routine. While . the exemplary 
embodiment uses only two levels of specification and uses pre-defined sets of ICD-9 
and CPT codes, other embodiments could have additional levels of other codes, could 

.15 use other types of codes (e.g., HCPC code's), could combine codes from multiple 
different code sets at one level, and could allow customization in which usei-defined 
codes replace or supplement pre-defined codes. 

Figure 23 is a flow diagram of an embodiment of the Hospital routine 
. *2300. The Hospital routine receives PCRs indicating authorized referrals with the 

20 hospital as the performing provider, assists a user in adding information about the 
hospital encounter to the PCR. and submits the PCR for payment to either the Paylist or 
the Adjudication module. The routine begins at step 2305 where all PCRs in the queue 
for the current Hospital routine are retrieved from the EMCC Server. The routine then 
continues to step 2310 to receive a user selection of a displayed PCR. 

25 After a PCR is selected, the routine continues to step 2320 to determine 

if the user has specified to discharge the patient. If .not, the routine continues to step 
2325 to retrieve the patient's medical history, including associated PCRs, so that it can 
be displayed. The routine then continues to step 2330 to determine if the user has 
specified to admit the patient. If so. the routine continues to step 2335 to add the 

30 admission date to the PCR. After step 2335. or if it is determined in step 2330 that the 
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user did not specify to admit the patient, the routine continues to step 2340 to add a 
journal entry related to the patient encounter. These entries may include service codes 
related to services provided. The routine then continues to step 2345 to determine 
whether the sendees corresponding to the journal entry are automatically authorized for 

5 payment. Those skilled in the art . will appreciate that this determination can be 
performed in a variety of ways, such as checking whether a specified service code can 
be automatically authorized based on the context of previously specified information or 
by requiring the user to flag exceptional journal entries when entered that are outside 
the normal scope of care. 

0 If it is determined in step 2345 that the services corresponding to the 

journal entry are not automatically authorized for payment, the routine continues to step 
2350 to set the PCR status to ^Unauthorized." After step 2350, or if the routine 
determined in step 2345 that the services were authorized, the routine continues to step 
2355 to determine if there are more journal entries to add to the PCR at this time. If so, 

5 the routine returns to step 2340, and if not, the routine continues to step 2360 to 
determine if the patient should be discharged at this time. If the patient is not to be 
discharged, the routine continues to step 2365 to invoke the Remote Distribution 
subroutine to return the PCR to the queue for the current Hospital module. 

If it is instead determined in step 2320 or step 2360 that the patient is to 

0 be discharged, the routine continues to step 2370 to add the discharge date to the PCR. 
The routine then continues to step 2375 to determine if the PCR status is 
"Unauthorized." If so ; the routine continues to step 2385 to invoke the Remote 
Distribution subroutine to send the PCR to the Adjudication module for manual 
determination of an authorized payment. If instead it is determined in step 2375 that the 

5 PCR, status is not "Unauthorized." the routine continues to step 2380 to determine the 
payment that will be received for the products used and services provided. The routine 
then continues to step 2390 to invoke the Remote Distribution subroutine to send the 
PCR to the Paylist module for immediate payment of the' determined amount. After 
steps 2365, 2385 ? or 2390 ? the routine returns -to step 2305. . 
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Figure 24 is a flow diagram of an embodiment of the Adjudication 
routine 2400. The Adjudication routine receives PCRs related to requests for payment 
for diagnoses and services which could not be automatically authorized, and assists the 
user to determine the payment for the services performed by displaying relevant 
5 information. The routine begins at step 2405 where all PCRs in the queue for the 
Adjudication routine are retrieved from the EMCC Server. The routine continues to 
step 2410 to receive a selection by the user of a displayed PCR. The routine then 
continues to step 2415 to display information stored in the selected PCR that is related 
to the request for payment, and then in step 2420 receives a user command. In step 

10 2425 it is determined if the user command is to retrieve additional information, and if 
so. the routine continues to step 2430 to retrieve and display the requested information 
from the EMCC Server and then returns to step 2420. 

If it is instead determined in step 2425 that the user command is not to 
retrieve additional information, the routine continues to step 2435 to determine the 

15 medical necessity for the services indicated by the service codes in the PCR. Those 
skilled in the an will appreciate that this can be determined in a variety of ways, such as 
by receiving textual comments from the user or by automatically analyzing services 
provided and supporting comments justifying the services. After step 2435, the routine 
"continues to step 2440 to select some or all of the service codes in the PCR to be 

20 authorized for payment. The routine then continues to step 2445 to determine a 
payment for the authorized service codes in the PCR. In step 2450, the routine 
determines whether the PCR should be submitted to the Paylist module. If so, the 
routine continues to step 2460 to invoke the Remote Distribution subroutine to send the 
; PCR to the Paylist module. If the routine instead determines in step 2450 not to submit 

25 the PCR, the routine continues to step 2455 to invoke the Remote Distribution 
subroutine to return the PCR to an Adjudication routine'. After step 2455 or 2460. the 
routine returns to' step 2405. 

Figure 25 is a flow diagram of an embodiment of the Paylist routine 
2500. The routine receives PCRs reflecting referrals and services performed that are 

30 authorized to be paid a determined amount, and then pays the determined amount. The 
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routine begins at step 2505 where it retrieves all PCRs from the EMCC server in the 
queue for the Paylist routine. The routine continues to step 2510 to select a retrieved 
PCR, and then continues to step 2515 to pay the determined amount. The routine then 
returns to step 2505 and continues to reimburse PCRs. Those skilled in the art will 
5 appreciate that this reimbursement can be performed in a variety of ways, such as by 
crediting bank accounts, electronic wire transfers, etc. 

From the foregoing it will be appreciated that, although specific 
embodiments of the invention have been described herein for purposes of illustration, 
various modifications may be made without deviating from the spirit and scope of the 
10 invention. Accordingly, the invention is not limited except as by the appended claims. 
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4.1 

CLAIMS 

1 . -A method in a computer system for controlling authorization for a 
medical referral of a patient from a referring provider to a performing, provider, the 
performing, provider to provide medical services authorized by the medical referral to the 
patient, the method comprising: 

displaying a list of choices each representing a patient ; 

in response to selection of a patient by indicating the representative displayed 
choice, displaying a list of referring provider choices each representing a medical service 
provider authorized to make a medical referral of the selected patient: 

in response to selection of a referring provider by indicating the representative 
displayed choice, displaying a list of performing provider choices each representing a medical 
service provider authorized to provide medical services to the selected patient; 

in response to selection of a performing provider by indicating the 
representative displayed choice, displaying a list of referral basis choices each representing a 
reason for the selected referring provider to make a medical referral of the selected patient to 
the selected performing provider; 

in response to selection of a referral basis by indicating the representative 
displayed choice, displaying a list of treatment suggestion choices each representing at least 
one medical service that the selected referring provider can suggest be provided to the 
selected patient by the selected performing provider; 

in response to selection of a treatment suggestion by indicating the 
representative displayed choice, determining whether an authorization of a referral can be 
obtained without human intervention, the referral being of the selected patient to the selected 
performing provider by the selected referring provider for the reason represented by the 
selected referral basis, the authorization allowing the selected performing provider to provide 
at least one of the medical services represented by the selected treatment suggestion; and 

when it is determined that the authorization of the referral is obtained, 
notifying the selected performing provider so that at least one of the medical services 
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represented by the selected treatment suggestion can.be immediately provided to the selected 
patient by the selected performing provider. 

2. The method of claim 1 including: 

after the notifying of the selected performing provider. 

displaying a list of diagnosis code choices each representing a medical 
diagnosis that the selected performing provider can make for the selected patient; 

in response to selection of a diagnosis code by indicating the 
representative displayed choice, displaying a list of service code choices each representing a 
medical service that can be provided to the selected patient by the selected performing 
provider to address the medical diagnosis of the selected diagnosis code: and 

in response to selection of a service code by indicating the 
representative displayed choice, determining whether an authorization can be obtained 
without human intervention for the medical service represented by the selected service code. 

3. The method of claim 2 wherein the medical service represented by the 
selected service code is determined to be authorized when the medical service is also 
represented by the selected treatment suggestion, and including: 

when the medical service is determined to be authorized, providing payment to 
the selected performing provider without human intervention by, 

determining a payment amount for the medical service; and 

providing the determined payment amount to the selected performing 

provider. 

. 4. The method of claim 2 wherein when the authorization of the medical 
service represented by the selected service code cannot be obtained without human 
intervention, payment is provided to the selected performing provider by notifying a manual 
review user of the referral. 
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5. The method of claim 2 including: 

automatically authorizing payment to the selected performing provider for 
providing to the selected patient the medical service of the selected service code if the 
medical service represented by the selected service code is one of the medical services 
represented by the selected treatment suggestion. 

6. The method of claim 5 wherein the automatic ' authorization of the 
payment includes: 

automatically determining a payment amount for the medical service 
represented by the selected service code: and 

automatically providing the determined payment amount to the selected 
performing provider. 

7. The method of claim 2 wherein the choices displayed in each list 
depend on the selected choices from previous displayed lists. 

8. The method of claim 2 including: 

after selection of a service code representing a medical service and in response 
to selection of any of a patient, a performing provider, a reason, a diagnosis code or a service 
code that is not a displayed choice, determining payment for providing the medical service by 
notifying a manual review user of the medical service. 

9. The method of claim 1 wherein each displayed choice is an 
auihorizable choice for that type of information such that an authorization can be obtained 
without human intervention for a referral including only authorizable choices, and wherein 
the authorizable choices for a type of information for the referral depend on previous 
selections for other types of information for the referral. 

10. The method of claim 1 wherein each of the displayed patient choices 
has insurance coverage for medical services, wherein each of the displayed referring provider 
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choices is authorized by the insurance coverage for the selected patient to make a medical 
referral of the selected patient, and wherein each of the displayed performing provider choices 
is authorized by the insurance coverage to provide medical services to the selected patient. 

11. A computer system for facilitating management of patient services, the 
system comprising: 

a first component having a referral sub-component and an authorization sub- 
component, the referral sub-component for verifying patient eligibility, for guiding selection 
of a performing provider and of a reason code for referral of a patient to the selected 
performing provider, and for automatic authorization when a combination of the selected 
performing provider and the selected reason code are pre-authorized. the authorization sub- 
component for soliciting authorization from an authorization manager when the combination 
of the selected performing provider and selected reason code are not pre-authorized; and 

a second component having a performing sub-component and an approval sub- 
component, the performing sub-component for providing to a performing provider an 
identification of a patient and a reason code for an authorized referral, for guiding selection of 
a diagnosis code reflecting a diagnosis for a referred patient, for guiding selection of a service 
code reflecting a service to be provided to a referred patient, and for automatic approval when 
a combination of the provided reason code, the selected diagnosis code, and the selected 
service code are pre-approved, the approval sub-component for soliciting approval from an 
approval manager when the combination of the provided reason code, the selected diagnosis 
code, and the selected service code is not pre-approved. 

12. The computer system of claim 11 wherein the second component 
includes a payment sub-component for controlling payment to the performing provider upon 
approval of the combination of the provided reason code, the selected diagnosis code, and the 
selected service code. 

13. The computer system of claim 11 wherein the referral sub-component 
of the first component is additionally for guiding selection of suggested medical services, and 
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wherein the performing sub-component of the second component is additionally for providing 
to a performing provider an identification of suggested medical services for an authorized 
referral. 



BNSDOCID: <WO 0003343A1_I_> 



WO 00/03343 



PCT/US99/15429 



(person seeks care) 



1/22 



Electronic Managed Care Commerce 
(EMCC) system 100 



f 



105 



Gatekeeper 
Module 



automatically 
authorized J 
referral 



120 



Performing 
Provider (PP) 
Module 



(person receives 



care) 



automatically 
authorized 
payment 
request 



request for manual 
authorization of 
referral 



110 



1 



115 



Authorization 
Module 



EMCC Server 

(exchanges 
information and 
coordinates activity) 



▲ ► 



manually 
authorized, 
modified, or 
denied referral 




T 



Adjudication 
Module 



i request for manual 
; authorization of 
payment request 



V, request for 

manual 
authorization 
of payment 
manually authorized/-. request 
modified or denied 
payment request 



automatically 
authorized 
payment 
request 

r 135 



Paylist 
Module 



(providers receive payment) 



Fig. 1 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



2/22 



PCT/US99/15429 

User Interface (UI) Screen 200 



Pendinc Patient Claim Records 



Identifier 


Member ID 


Name Date 


Review 
Level 


Urgency 


0000S3 
000127 
000095 


"183X5*02 

512-85-9299*0 

"183X5*05 

• 


Aag, Bob 08/1 5/XX 
Tan, Jill 08/14/XX 
Aag, Bob 0S/15/XX 


UR Urgent 
UR Routine 
Case Emergency 
Manager 


( 


Create New PaLtjeat; 






iS§|?;/; , ..J 


V 








J 






Fig- 2 




UI Screen 300 



Create/Edit Patient Claim Records 



Identifier 
000153 



Member ID 



Name 



Date 

08/16/XX 



Review Urgency 
Level 



Member List 



Screen 1 of 8 



Name 



Member ID Insurance Primary Care 

Plan Provider 



Provider 
Code 



Aag, Bob 7183x5 NYL Wu, Jan VP 11 

Anderson, Paul 8357W4 NYL Smith, Ted VP12 

Bige, Barbara 587-88-9234 UPWMED Wu, Jan VP1 1 




SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 



.3/22 



UI Screen 400 



Create/Edit Patient Claim Records 

Identifier Member ID Name Date Review Urgency 

Level 

000153 08/1 6/XX 



View Patient Elieibilirv and Information Screen 1 A of 8 



Patient Name: Anderson. Paul 

Patient Member ID: 8357W4 

Patient DOB: 06/18/32 Gender: M 

Primary Care Provider Name: Smith, Ted MD Code: VP12 

Insurance Plan: NYL 

Last Eligibility Verification: 07/3 1/XX 

On-going Conditions: Asthma, Diabetes 




Fig. 4 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 







4/22 


UI Screen 500 


r 




Create/Edit Patient Claim Records 


\ 


Identifier 


\ A & ni V\ r* I l"^ 

ivicrnncr iu 


Vamp DatP 


Review Uniencv 
Level 


000153 


S357W4*07 


Anderson, Paul 08/1 6/XX 








Referral History 


Screen 2 of 8 


Trlrntififr 


Member ID 


Date Referral 
Basis 


Referral Treatment 
Type Suggestion 






- Problems 


AT T- A Itprnati vc 

Care 


000151 


8357W4*06 


08/13/XX CA002-Heart 

Problems 


CD1- Diag/ 

Stablilize 




V 









Fig. 5 



UI Screen 600 



Create/Edit Patient Claim Records 
Identifier Member ID Name Date 



Review Urgency 
Level 



000153 



S357W4*07 Anderson, Paul 08/16/XX 



Name 



Code 



Referring Provider List 

Insurance Plan Affiliations 



Screen 3 of 8 



Smith, Ted MD VP 12 
H ilter, Sally MD VP23 
Tang, Bob RN VOl 05 



NYL. Blue Cross WA/AK 
NYL 



Show All 



View;Additioria 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO 0003343Al_t„> 



WO 00/03343 



PCT/US99/15429 



5/22 



UI Screen 700 



Create/Edit Patient Claim Records 

Identifier Member ID Name Date 
000153 8357W4*07 Anderson, Paul 08/16/XX 



Review Urgency 
Level 



Name 


Performinc Provider List 
Code Specialty 


Screen 4 of 8 


Mendez, Roberto MD 


V083 


Cardiology 




Mercy Cardiology Dept. 


ME24 


Cardiology 




Oster, Jennifer MD 


V0723 


Internal Medicine 




Hiher, Sally MD 


VP23 


None 






Fig. 7 



UI Screen 800 



Create/Edit Patient Claim Records 

Identifier Member ID Name Date 
000153 8357W4*07 Anderson, Paul 08/16/XX 



Review Urgency 
Level 





Referral Basis List 


Screen 5 of 8 


CA050 


- Arrhythmia 




CA051 


- Congestive Heart Failure 




CA052 


- Heart Tumors 




CA053 


- Heart Valve Disorder 








i 



Fig. 8 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 



.6/22 



UI Screen 900 



Create/Edit Patient Claim Records 

Identifier Member ID Name Date 
000153 S357W4*07 Anderson, Paul 08/1 6/XX 



Review Urgency 
Level 





Type of Facility List 


Screen 6 of 8 


IN - 


In-Patient Facility 




OFF- 


Physician Office 




OUT- 


Outpatient Department 




REII - 


Rehab Medical Department 





Show A41 



sen 



'^em- 



Fig. 9 



UI Screen 1000 



Create/Edit Patient Claim Records 

Identifier Member ID Name Date 
000153 S357W4*07 Anderson, Paul 08/16/XX 



Review Urgency 
Level 



Referral Treatment Type Suggestion List Screen 7 of 8 



COl - 


Consult 


CP1 - 


Evaluate & Treat 


LAB - 


Laboratory Tests 


OFC- 


Office Visit 


PROC- 


Procedure Only 


TPJEAT - 


Treatment Only 


XR- 


X-Rays Diagnostic 



Show.AU 



:PreyiQUs: 



Fig, 10 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 



7/22 



UI Screen 1100 



Create/Edit Patient Claim Records 
Identifier Member ID Name Date 

000153 S357W4*07 Anderson, Paul 08/1 6/XX 



Review Urgency 
Level 

UR 



Urgency List 



Screen 8 of 8 



Routine 
Urgent 

Emergency 






mi 



Fig. 11 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO 0003343A1 J_> 



WO 00/03343 



8/22 



PCT/US99/I5429 



UI Screen 1200 



r 



Review Patient Claim Record 



Identifier: 000153 
Patient Name: Anderson, Paul 
Patient Member ID: 8357W4*07 
Insurance Plan: NYL 

Associated Patient Claim Recoords: 000151 (CA002-CD1) 

Primary Care Provider: Smith, Ted MD VP12 

Referring Provider: Hilter, Sally MD VP23 

Performing Provider: Mendez, Roberto MD V083 Cardiology 

Referral Bases: CA050 - Arrhythmia, CA053 - Heart Valve Disorder 

Type of Facility: OFF - Physician Office 

Referral Treatment Type Suggestions: LAB - Lab Tests, XR - X-Rays Diag 
Urgency: Urgent 

Review Level: UR 

Relevant Risk Factors: Diabetes, Age > 60 



Submit 




Fig. 12 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 



9/22 



Ul Screen 7300 



Complete/Edit Patient Claim Records 



Identifier Member ID Name 
000153 8357W4*07 



Referral Referral Treatment 

Bases Type Suggestions 

Anderson, Paul CA050,CA053 LAB, XR 



ICD-9 Diagnostic Code List 



416. 

416.1 

416.9 

746.1- 
746.9 



CHR Pulmonary Heat Disease 

Kyphoscoliotic Heart Disease 
CHR Pulmon Heart Dis NOS 

Other Congenital Heart Anomaly 



Show All 





Fig. 13 



UI Screen 1400 



Complete/Edit Patient Claim Records 
Identifier Member ID Name 



000153 S357W4*07 



Anderson, Paul 



Referral Referral Treatment 

Bases Type Suggestions 

CA050,CA053 LAB, XR 



CPT Product Code List 



99203 New Pat. Office Longer 

99401 Preventative Med 15 min 
23705 Diaenostic Heart X-Ravs 



Show All 



Fig. 14 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCIO: <WO_0003343A1.I_> 



WO 00/03343 



PCT/US99/15429 



1 0/22 



UI Screen 1500 



r 



Review Patient Claim Record 



Identifier: 000153 
Patient Name: Anderson, Paul 
Patient Member ID: 8357W4*07 
Insurance Plan: NYL 

Associated Patient Claim Recoords: 000151 (CA002-CD1) 

Primary Care Physician: Smith, Ted MD VP12 

Referring Provider: Hiker, Sally MD VP23 

Refcrred-To Providers: Mendez, Roberto MD V083 Cardiology 

Referral Bases: CA050 - Arrhythmia, CA053 - Heart Valve Disorder 

Type of Facility: OFF - Physician Office 

Referral Treatment Type Suggestions: LAB - Lab' Tests, XR-X-Rays Diag 
Urgency: Urgent 
Review Level: UR 

Relevant Risk Factors: Diabetes, Age > 60 
ICD-9 Codes: 416,746.1-746.9 
CPTCode: 99203 
Reimbursement: $730.- 



Submit 





Fig, 15 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



PCT/US99/15429 



1 1 /22 




8NSDOCID: <WO 0003343A 1_l_> 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



12/22 



PCT7US99/15429 



Fig. 17A 



1740' 



Retrieve existing 
PCR 



^Gatekeeper Routine 




Retrieve all 
PCRs from 
queue in 
EMCC Server 



Receive indication to 
create a new PCR or 
to select an exisune 
PCR 



Yes 



Select insurance plan 
member information 
for patient 



Verify patient 
eligibility 



1700 




Yes 



Create blank PCR to 
hold information for 
the current referral 



1705 



1710 




1715 



1720 



1725 



1735 



Associate current 
PCR with other 
PCRs 



1745 





B 



8NSOOCID: <WO 0003343A1 J_> 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



13/22 



PCT/US99/15429 




1750 




Designate referral 
information 




1770 



Invoke Remote 
Distribution 
subroutine to send 
PCR to 
Authorization 
module for manual 
approval 



Yes 



1775 



1765 




Invoke Remote 
Distribution 
subroutine to send 
PCR to PP module 
for performing 
provider 



1780 



Invoke Remote 
Distribution 
subroutine to send 
PCR to interested 
users 



/~ 1762 



Reset PCR status so it 
is not "Unauthorized" 



1764 



Invoke Remote 
Distribution routine 

to return PCR to 
current Gatekeeper 
routine 




Create blank PCR with 

patient information 
and referring provider 
specified 



Fig. 17B 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



1 4/22 



PCT/US99/15429 



Designate Referral \ /" 1850 
Information Subroutine , 




Receive PCR 



Compile history of past treatment from 
current and associated PCRs 



Based on member information and past related 
treatment, select a referring provider who will 
make the referral 



Based on referring provider and past related 
treatment, select a performing provider who will 
receive the referral 



Based on referring provider, past related treatment, 
and performing provider, select a referral basis 
indicating why referral was made 



Based on referring provider, past related treatment, 
performing provider, and referral basis, select a 
type of facility for referral 



Based on referring provider, past related treatment, 

performing provider, referral basis and type of 
facility, select a referral treatment type suggestion 



Determine urgency of treatment for referral 
based on current selections 



Determine patient risk factors for referral 
based on current selections 



1805 



1815 



Determine manual review level for referral based on 
current selections * 



Add determined risk factors and treatment 
urgency to PCR 



c 



RETURN 



1875 



1825 



1835 



1840 



1845 



1850 



1855 



1860 



1865 



1870 



Fig. 18 



BNSDOC1D: <WO 0003343A1J > 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



15/22 



PCT/US99/I5429 



Fig. 19 



1900 



1905- 




Select An Instance Of Specified 
Type Of Informanon Based On 
Specified Context Of Past Selections 



Receive PCR and history of related past treatment 



1920 



Does PCR 

'already have a satisfactory selected choice" 
for the specified type of referral 
information? 



Yes 



1915' 



1925' 



1930- 



1935- 



1950- 



No 



Determine choices for specified type 
of information in associated PCRs 



Based on the past selections for the current PCR, 

identify choices for the specified type of 
information that can be automatically authorized 



Set PCR status to "Unauthorized" 



Display list of identified choices, 
including an indication of 
determined choices for associated PCRs 



Receive selection of a choice from user 




1940 



Add selected choice to PCR 



1960 



RETURN 




7965 



BNSDOCID: <WO 0003343A 1J_> 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



1 6/22 



PCT/US99/15429 



Fig. 20A 



/Remote Distribution\/^ 2000 
V Subrou tine 



2005 



Receive indication of 
PCR and of destination 



2016 



Create message 
including PCR 
information 



2015 



Check distribution 
destination 



2020 



2035 



2030 



Determine appropriate 
users to review PCR for 
manual authorization 



Yes 



2040 



Send message to 
Authorization modules 
for determined users and 

place PCR in the 
module queues 




2025 



Yes 



Place PCR in queue 
for Gatekeeper module 
for referring provider 



^ 2050 



Yes 



2055 



Determine users 
interested in PCR 





2060 
2070 



Yes 



Send message to 
determined users 



Place PCR in 
queue for Hospital 

module of PCR 
performing provider 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 0003343A1_I_> 



WO 00/03343 



PCT/US99/15429 



1 7/22 




c 





D 



2075 



Determine appropriate 
users to review PCR 
for payment 
adjudication 



Send message to 
Adjudication modules 
for determined users 
and place PCR in the 
module queues 




2077 



Place PCR in queue for 
PP module of PCR 
performing provider 



Place PCR in Paylist 
module queue 




2092 



Send message to 
Gatekeeper module for 
referring provider and 
to PP module for PCR 
performing provider 



RETURN 




2094 



Fig. 20B 



BNSDOCID: <WO 0003343A1 J_> 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



18/22 



PCT/US99/15429 



Fig. 21 



Retrieve all PCRs 
from EMCC Server 
in queue for this 
Authorization 
module 



■2125 
Yes 



Receive user 
selection of a PCR 



Display PCR 
information 



2730 



2135 




2100 



2110 



Receive indication 
of PCR 



Display information 
stored in PCR 



2120- 



Receive user 
command 



Receive user command 



2140 




Retrieve and display 
requested 
information from 
EMCC Server 



2150 



Modify PCR referral 
as indicated 



Invoke Remote 
Distribution 
subroutine to 
notify referring 
and performing 
providers as well 
as other users 
interested in 
denial 



2160 



2175 



2170 



Reset PCR status so 
it is not 
"Unauthorized" 



2190 



Invoke Remote 
Distribution 
subroutine to 
return PCR to an 
Authorization 
module 



Invoke Remote 
Distribution 
subroutine to send 
PCR to PP module 
for performing 
provider 



BNSDOCID: <WO 0003343A1J_> 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 



19/22 



PCT/US99/15429 



Fig. 22 



> eribrming Provider\ /- 2200 
(PP) Routine V 



2210' 



2215 



Receive user selection of PCR 



2205- 



Retneve all PCRs from 
EMCC Server in queue for 
this PP module 



Receive additional 
patient medical history 



Based on insurance plan, patient, referring provider, 
performing provider, referral basis, type of facility, referral 
treatment type suggestion, and related past treatment, select an 
ICD-9 diagnosis code for the patient 



2225 



Based on previous factors and selected ICD-9 code, 
select a CPT service code indicating product 
or service supplied by performing provider 



2230 



Add selected ICD-9 code 
and CPT code to PCR 



2235 



2240 



Yes 



2265 



Determine the payment 
that will be received 



2270 



IX. 




2250 



Reset PCR status so it is 
not "Unauthorized" 



Invoke Remote 
Distribution subroutine 
to send PCR to 
Paylist module 



Yes 



2255 



Invoke Remote 
Distribution 
subroutine to return 
PCR to current 
PP module 



2275 



Invoke Remote 
Distribution 
subroutine to send 
PCR to an 
Adjudication module 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 0O03343A1_l_> 



WO 00/03343 



20/22 



PCT/US99/15429 



Fig. 23 



Hospital Routine 




2300 



Retrieve ail PCRs from EMCC Server 
in queue for this Hospital module 



2305 
2370 



Receive user selection of a PCR 



Yes 




2320 



Retrieve additional patient medical history 



2325 




2330 



Add admission date to PCR 



2350 



Add journal entry related to encounter to PCR 



Set PCR status to 
"Unauthorized" 



2345 



2355 



Yes 




2335 
2340 



/~2365 



Invoke Remote 
Distribution subroutine to 
return PCR to current 
Hospital module 



Add discharge date to PCR 



Yes 




2370 



y- 2380 



Determine the payment 
that will be received 



Invoke Remote 
Distribution subroutine 

to send PCR to 
Adjudication module 
1 



2335 



2390 



Invoke Remote 
Distribution subroutine 
to send PCR to 
Paylist module 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 00033 43A 1_l_> 



WO 00/03343 



Fig. 24 



21/22 

^Adjudication Routine 



PCT/US99/15429 




2400 



Retrieve all PCRs 
from EMCC Server 

in queue for this 
Adjudication module 



2405 



Receive user 
selection of PCR 



2430 





Display information 
stored in selected 
PCR 


I * 

V 




Receive user 
command 



2410 



2415 



2420 



Retrieve and display 
requested 
information from 
EMCC Server 



2425 




Determine 
medical necessity 
for products given 

and services 
performed in PCR 



2435 



Select the portion of 
PCR to be authorized 



2440 



2455 "x 



Determine the 
payment for 
authorized portion 
of PCR 



2445 



Invoke Remote 
Distribution 
subroutine to 
return PCR to 

an Adjudication 
module 




2460 



Invoke Remote 
Distribution 
subroutine 
to send PCR to 
Paylist module 



SUBSTITUTE SHEET (RULE 26) 



WO 00/03343 PCT/US99/1S429 

22/22 



C 



Paylist Routine 




Retrieve all PCRs 
from EMCC Server 
in queue for this 
Paylist module 



2500 



2505 



2510 



Select PCR 





Pay determined 
amount for 
selected PCR 







2515 



Fig. 25 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 0003343A1_I_> 



INTERNATIONAL SEARCH REPORT 



tnteri nal Application No 

PCT/US 99/15429 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G06F19/00 G06F17/60 



According (o International Patent Classification (IPC) or to both national classification and (PC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G06F 



Documentation searched other than minimum documentation to the ettent that sucn documents are included in the fields searched 



electronic aata base consulted during the international search (name ot data base ano. where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category i 



Citation ot document, with indication, where appropriate, of the relevant passages 



US 5 359 509 A (GINGRICH MARK ET AL) 
25 October 1994 (1994-10-25) 
abstract; figures 5,9 
column 1, line 35 - line 42 
column 4, line 21 - line 44 

US 5 325 293 A (DORNE HOWARD L) 
28 June 1994 (1994-06-28) 
abstract 

column 1, line 14 - line 30 
column 2, line 32 - line 56 
column 3, 1 ine 29 - 1 ine 39 

US 4 491 725 A (PRITCHARD LAWRENCE E) 
1 January 1985 (1985-01-01) 
abstract 

column 3, line 29 - line 52 

-/— 



Relevant to claim No. 



I. 3-6, 

II, 12 



1,11 



1,11 



Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



J Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
M E" earlier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance: the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance: the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of the international search 

21 October 1999 


Date ot mailing of the international search report 

28/10/1999 


Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Ftijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 


Authorized officer 

van der Wei den, A 



Form PCT/1SA/210 (second sheet) (July 1992) 



BNSOOCID: <WO 0003343A1_L> 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



Interi nal Application No 

PCT/US 99/15429 



C,{Continuation> DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ■ 



Citation of document, with indication. where appropriate, of the relevant passages 



Relevant to claim No. 



US 5 483 443 A 
9 January 1996 
abstract 
column 1, line 
column 3, line 

US 4 858 121 A 
15 August 1989 
abstract 
column 1, line 
column 3, line 



(MILSTEIN BERNARD A ET AL) 
(1996-01-09) 



10 -column 
65 -column 



1 ine 
1 ine 



(BARBER WILLIAM 
(1989-08-15) 



B ET AL) 



5 - line 16 
55 -column 4. 



line 10 



1,11 



1,11 



Form PCT/1SA/210 (continuation oi second sheet) (July 1992) 
BNSOOCID: <WO 0003343A1_I_> 



page 2 of 2 



Information on patent family members 


Interr ->al Application No 

PCT/US 99/15429 


Patent document 
cited in search report 


Publication 
date 


Patent family j Publication 
rnember(s) j date 



US 5359509 
US 5325293 



A 
A 



25-10-1994 
28-06-1994 



CA 2081737 A 
NONE 



01-05-1993 



US 


4491725 


A 


01-01-1985 


EP 


0120077 


A 


03-10-1984 










WO 


8401448 


A 


12-04-1984 


us 


5483443 


A 


09-01-1996 


NONE 








us 


4358121 


A 


15-08-1989 


NONE 









Form PCT/ISA/21 0 (patent family annox) (July 1 992) 
BNSDOCID: <WO 0003343A1_I_> 



